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1.  General  Description  of  Operational  Capability 

The  Joint  Simulation  System  (JSIMS)  will  be  a  core  of  common  and  joint  representations  and  services,  a 
run-time  hardware  and  software  infrastructure,  and  interfaces,  that  is  augmented  by  the  representations 
of  Air/Space,  Land,  and  Sea  Warfare  Functionality.  The  representations  of  Air/Space,  Land,  and  Sea 
Warfare  Functionality  will  be  provided  via  sponsorship  by  Executive  Agents.  The  primary  focus  of 
JSIMS  at  Initial  Operational  Capability  (IOC)  and  Full  Operational  Capability  (FOC)  will  be  training. 
JSIMS  will  utilize  authoritative  representations  of  the  environment  (natural  ^d  man-made),  systems, 
and  behaviors  to  create  a  capabilities  to  create  synthetic  representations  and  interactions  within  the 
synthetic  environment  for  training.  The  JSIMS  infrastructure  vwll  interface  with  users  via  training 
systems  and  operational  command,  control,  communications,  computers  and  intelligence  (C4I)  systems. 

JSIMS  will  support  Unified  Combatant  Commands,  Service,  and  Joint  Task  Force  (JTF)  training  in  all 
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phases  of  military  operations  (i.e.,  mobilization,  deployment,  employment,  sustainment,  and 
redeployment  activities)  and  operations  other  than  war  (OOTW).  JSIMS  will  be  employed  by  the 
combatant  commands  in  configurations  and  modes  relevant  to  the  unique  requirements  of  their 
respective  theaters  or  missions.  JSIMS  will  specifically  support  the  training  required  by  their  Joint 
Mission  Essential  Task  Lists. 

JSIMS  will  provide  a  capability  to  simulate  the  actions  and  interactions  of  all  entities  (e.g.,  platforms, 
weapons,  sensors,  units,  C4I  systems,  etc.)  within  a  designated  area  of  operations  as  influenced  by  the 
environment,  system  capability,  and  human  and  organizational  behavior  affecting  the  achievement  of 
missions  and  objectives  for  that  area  of  operations. 

Though  initially  focused  at  the  operational  level  of  war  for  both  combat  operations  and  OOTW,  JSIMS 
will  be  extensible  to  the  strategic  level  (e.g.,  activities  involving  multiple  Commander  In  Chiefs  (CINCs) 
and/or  theaters)  and  to  the  tactical  level  (e.g.,  the  prosecution  of  individual  battles  or  engagements)  to 
support  multi-echelon  exercises  and  contingency  planning.  Therefore,  JSIMS  will  be  able  to  support 
training  (i.e.,  strategic-national,  strategic-theater,  operational,  and  tactical  tasks)  identified  by  the 
Universal  Joint  Task  List  published  by  the  Joint  Staff  (JSM  3500.04). 

In  addition  to  planning  and  training  activities,  as  the  underlying  JSIMS  architecture  matures,  it  will  also 
provide  a  flexible  framework  to  the  Department  of  Defense  (DoD)  community  at  large  to  support 
evaluation  of  doctrine. 

JSIMS  will  provide  consistent  representations  of  across  the  synthetic  environment  through  disciplined 
use  of  standard,  accredited  descriptions  for  all  Joint  and  Service  mission  areas  (land,  sea,  air,  and  space). 
All  military  functionality  will  be  represented  including  combat,  combat  support,  special  operations, 
combat  service  support  (logistics),  C4I,  inter-  and  intra-theater  transportation.  JSIMS  will  employ 
consistent  representations  of  the  natural,  physical  environment  (i.e.,  land,  ocean,  atmosphere,  and  space) 
with  the  level  of  detail  required  to  meet  the  user's  needs.  These  representations  will  be  provided  by  the 
designated  DoD  Executive  Agents.  Similarly,  all  potential  opposing  forces  (OPFOR),  allies,  and  neutrals 
will  be  represented  at  the  user's  required  level  of  detail. 

JSIMS  will  operate  in  a  distributed  environment  interacting  with  live,  virtual,  and  constructive 
simulations  with  the  capability  to  operate  a  subset  of  JSIMS  in  a  stand-alone  (scaleable,  part  task)  mode. 
JSIMS  will  foster  interoperability  that  allows  interaction  of  synthetic  environment  activities  required  to 
emulate  joint  military  operations.  JSIMS  will  enable  users  to  create  a  cohesive  training  environment 
despite  extended  geographical  separation  of  the  participants. 

Prior  to  an  exercise,  JSIMS  will  provide  the  capabilities  to  perform  distributed  scenario  development 
and  collaborative  planning.  During  an  exercise,  JSIMS  will  provide  model  execution  which  simulates  all 
forces  (joint  and  coalition).  JSIMS  will  also  provide  an  After  Action  Review  (AAR)  function  to  support 
rapid  turnaround  of  exercise  results. 

JSIMS  will  provide  support  training  by  interacting  with  the  training  audience  through  interfaces  to 
actual  C4I  systems  and  existing  organizational  equipment  in  a  manner  indistinguishable  from  real-  world 
operational  interaction.  JSIMS  will  reduce  the  overhead  associated  with  current  simulation-supported 
training,  through  reductions  in  role  player  and  controller  requirements. 

JSIMS  will  support  realistic  wartime  and  OOTW  scenarios,  allowing  commanders  and  their  staffs  to  be 
trained  in  the  proper  assessment  of  conditions,  allocation  and  management  of  resources,  and  decision 
making  under  the  pressures  of  simulated  real-time  combat  and  non-combat  environments.  Training  for 
OOTW  operations  may  involve  the  US  Armed  Forces,  host  nation  and  other  coalition  forces,  US 
government  agencies,  non-govemment  agencies,  and  international  organizations. 

OOTW  may  include,  but  is  not  limited  to,  the  following:  arms  control,  combating  terrorism,  DoD 
support  to  counter-drug  operations,  nation  assistance,  noncombatant  evacuation  operations,  humanitarian 
assistance,  disaster  relief,  and  others  as  identified  in  the  National  Military  Strategy  and  Joint  Publication 
3-07. 
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2.  Threat:  Not  Applicable 

3.  Shortcomings  of  Existing  Systems 

With  the  existing  training  simulation  systems,  a  robust,  complete  electronic  representation  of  the 
operational  environment  cannot  be  created  without  excessive  overhead  in  personnel,  time,  and  other 
resources.  Examples  of  shortcomings  in  the  existing  systems  are: 

a.  Each  of  the  Services  have  independent  systems  that  support  Service-specific  or 
function-specific  needs.  While  these  legacy  systems  have  served  their  purpose  with  respect  to  the 
individual  Service  training  needs,  they  presently  do  not  adequately  or  efficiently  interoperate  with 
other  Service  models  to  satisfy  all  the  theater  commander/JTF  training  needs. 

b.  The  existing  simulation  models  that  replicate  functions  such  as  logistics,  intelligence,  space, 
and  special  operations  do  not  interact  with  sufficient  resolution  and  fidelity  with  combat  models. 

c.  The  combat  adjudication  process  in  current  models  developed  by  the  Joint  and  Service 
communities  does  not  replicate  a  complete  operational  environment. 

d.  There  is  no  standard  method  to  incorporate  consistent,  natural,  or  physical  environmental 
effects  in  a  simulation  effort  attempting  to  integrate  two  or  more  models. 

e.  Existing  simulations  do  not  adequately  replicate  OOTW  scenarios.  Social,  economic,  and 
political  factors  affecting  missions  across  the  full  range  of  military  operations  are  not  adequately 
modeled  to  support  joint  training. 

f  Existing  Service  simulations  require  high  manning  levels  for  Service  and  Joint  exercises. 
Deficiencies  in  current  models  require  personnel  vice  automation  to  represent  the  actions  of  higher 
and  lower  echelons  of  friendly  forces  that  are  not  actually  participating  in  the  exercise,  as  well  as, . 
Personnel  must  also  execute  the  actions  of  the  enemy.  Also,  substantial  personnel  augmentation  is 
required  to  operate  the  computer  systems  and  to  manually  enter  plans,  instructions  and  orders  to 
support  the  training  scenario. 

g.  It  is  difficult  and  expensive  to  make  significant  enhancements  to  the  existing  models  and  it  may 
no  longer  be  cost-effective  to  update  the  models  to  support  evolving  Joint  and  Service  training 
requirements.  Proprietary  software,  limited  graphics  capabilities,  non-modular  design,  and 
hard-coded  data  representations  do  not  integrate  easily  into  an  open  systems  environment. 

h.  The  existing  simulation  systems  do  not  provide  the  users  the  ability  to  freely  interact  with  each 
other  through  the  simulation,  nor  can  they  leverage  other  simulation  capabilities  through 
electronic  connectivity.  The  major  reasons  for  this  are  as  follows: 

(1)  CINCs  and  other  simulation  users  are  not  adequately  linked  for  complete  inter-Service 
functionality. 

(2)  Combat  simulations  are  not  fully  compatible  with  existing  C4I  systems 

(3)  Lack  of  a  common  supporting  infrastructure  has  led  to  the  creation  of  independent 
simulation  development  projects  which  exacerbate  our  inability  to  interoperate  and 
ultimately  raise  costs  and  degrade  performance. 

i.  Existing  simulations  do  not  effectively  link  the  phases  of  conflict. 

In  general,  existing  systems  do  not  allow  the  simulation  to  interface  with  existing  C4I  systems  in  a 
comprehensive  fashion.  Existing  simulations  require  specialized  equipment  to  display  geographic  and 


4  of  22 


Operational  Requirements  Document 


situational  information.  There  are  also  limitations  in  the  design  of  human  interface  equipment  supporting 
the  C4I  systems.  Therefore,  users  are  often  forced  to  participate  in  simulation  supported  events  using 
unfamiliar  equipment  and  interfaces. 

4.  Capabilities  Required 

a.  System  Performance 


JSIMS  will  provide  the  ability  to  execute  joint  exercise  scenarios  and  the  capabilities  to 
train  JTF  and  JTF  component  staffs,  Service  staffs,  and  subordinate  units  staffs.  The  system 
will  support  the  interaction  of  live,  virtual,  and  constructive  simulations  and  the  training 
systems/simulators  necessary  to  support  both  Joint  and  Service  training.  Adherence  to  the 
DoD  High  Level  Architecture  (HLA)  is  required  to  ensure  interoperability  across  the  full 
spectrum  of  the  joint  operations  mission  space  as  well  as  automated  connectivity  to  C4I 
systems.  The  HLA  will  provides  a  standardized  foundation  for  consistent  and  reliable  data 
exchange  between  live,  virtual,  and  constructive  simulations.  Compliance  with  the  HLA  is 
also  necessary  to  foster  maximum  reuse  of  simulation  components. 

At  IOC  (FY99),  JSIMS  must  provide  a  simulation  system  with  a  full  spectrum  of  integrated 
joint  warfare  functionality  and  automated  C4I  interfaces  that  supports  training  for  of  JTF 
battle  staffs.  As  a  minimum  threshold,  JSIMS  must  exceed  the  functionality  demonstrated 
by  the  FY99  Aggregate  Level  Simulation  Protocol  (ALSP)  Confederation  of  models. 

At  FOC  (FY03),  JSIMS  must  include  integration  of  live,  virtual,  and  constructive 
simulations  to  support  high  fidelity  applications  such  as  mission  rehearsal  and 
interoperability  with  emerging  joint  analysis  tools. 

(1)  Functional  Overview 

JSIMS  must  provide  a  coherent  time  and  space  representation  of  the  environment  (natural 
and  man-made),  entities,  activities  and  interactions.  This  representation  must  remain 
consistent  for  all  participants  even  when  operating  in  a  distributed  mode  at  dispersed 
geographic  sites. 

In  order  for  JSIMS  to  support  these  requirements  to  create  a  consistent  mission  space 
representation,  measurable  descriptions  of  the  synthetic  environment,  its  components,  and 
activities  must  be  developed  and  maintained  as  the  standard  for  all  JSIMS  developers  and 
users.  Standard  descriptions  are  required  for  such  components  and  activities  as: 
organizations  and  their  tasks,  system  and  materiel  performance,  and  warfighter/civilian 
characteristics  and  behavior.  Descriptions  are  required  for  all  US,  allied,  opposing  and 
neutral  military  forces  and  civilian  activities  required  to  be  represented  in  a  joint  exercise. 
The  JSIMS  synthetic  environment  includes  representations  of:  terrain,  oceans,  atmosphere, 
and  space;  as  well  as  the  effect  of  natural  and  man-made  processes  (e.g.,  changes  in  vehicle 
trafficability  due  to  rains  or  bomb  craters  in  the  road). 

The  goal  of  the  current  Conceptual  Model  of  the  Mission  Space  (CMMS)  project  is  to 
provide  an  HLA  compliant  representation  of  the  mission  space.  Wherever  practical,  JSIMS 
designated  Executive  Agents  for  Land,  Air/Space,  Sea,  and  Environment  will  exp^d  or 
modify  the  CMMS  to  meet  JSIMS  requirements.  Verification,  validation,  and  certification 
procedures  must  be  developed  and  implemented  to  ensure  that  accurate  and  realistic  data 
exists  in  each  of  the  pieces  contributed  to  JSIMS  firom  the  designated  Executive  Agents. 

The  JSIMS  mission  space  definition  will  expand  to  include  the  entities  and  behaviors 
necessary  to  support  OOTW  scenarios.  At  FOC,  this  includes  the  portrayal  of  national  and 
international  agencies,  non-aligned  forces,  and  noncombatant  groups  or  factions.  Factors 
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such  as  the  degree  of  participation  in  a  coalition  and  switching  allegiances  must  be 
considered.  Future  OOTW  areas  that  JSIMS  may  be  capable  of  simulating  include  support 
to  insurgency  and  counterinsurgency,  anti-terrorism,  peacekeeping,  shows  of  force  and  other 
small  contingencies,  and  support  to  counter  drug  operations. 

JSIMS  will  also  provide  common  support  services  such  as:  user  interface  tools  and  utilities, 
data  definitions,  storage,  distribution  capabilities,  operating  system  interface,  system 
management,  exercise/scenario  generation  capability,  and  application  programming 
interfaces  to  the  common  support  services.  JSIMS  will  also  provide  automated  interfaces  to 
designated  C4I  systems  and  an  integrated  after  action  review  (AAR)  capability. 

(2)  System  Attributes 

(a)  System  Flexibility: 

The  JSIMS  architecture  must  provide  for  future  development  and  system  enhancements  that 
will  evolve  as  new  requirements  are  generated.  It  must  be  developed  to  allow  for  the 
incorporation  of  technological  advances  in  hardware  and  software  technologies.  Where 
feasible,  emerging  technologies  successfully  demonstrated  by  ARPA's  Synthetic  Theater  of 
War  (STOW)  and  other  Advanced  Distributed  Simulation  (ADS)  projects  will  be  leveraged. 


JSIMS  will  be  compatible  with  existing  network  and  interface  systems  infrastructure 
to  facilitate  implementation  .  However,  the  system  will  be  robust  enough  to  capitalize 
on  emerging  hardware  and  software  interface  technologies. 

JSIMS  must  have  the  ability  to  add  and  delete  workstations  and  reconfigure 
workstation  functionality  as  required  by  the  particular  process  (i.e.,  training,  plaiming, 
or  test  and  evaluation  support). 

(b)  Distributed  Capability: 

JSIMS  will  support  distributed  simulation  operations  that  allow  exercise  participants  to 
receive,  process,  and  transmit  commands  and  information  to  geographically  dispersed 
locations. 

To  support  a  variety  of  exercise  configurations,  JSIMS  will  provide  a  modular  simulation 
capability  to  permit  operation  as  a  stand-alone  system,  or  in  combination  with  designated 
applications.  JSIMS  will  be  capable  of  operating  in  either  a  local  (single  site)  or 
remote/distributed  (multiple  site)  configuration.  Pre-exercise  training  of  operators  must  be 
supportable  in  each  configuration. 

(c)  System  Performance  Monitoring: 

JSIMS  must  provide  the  capability  to  monitor  system  performance,  detect  degradation,  and 
notify  exercise  controllers.  Exercise  controllers  require  the  option  to  continue  system 
operation  in  a  degraded  mode  when  warranted  by  exercise  requirements.  Exercise 
controllers  must  be  provided  an  option  to  either  continue  system  operation  in  a  degraded 
mode  when  warranted  by  exercise  requirements  or  stop  the  exercise  when  system 
performance  is  degraded  to  an  unacceptable  level. 

(d)  Security: 

JSIMS  must  provide  multi-level  security  capabilities,  ranging  from  Unclassified  to  Top 
Secret,  simultaneously.  Security  capabilities  will  include  segregation  by  categories  (NATO, 
NOFORN,  SCI,  etc.).  JSIMS  will  require  protection  from  unauthorized  access  and  will 
require  protection  from  information  security  (INFO SEC)  threats  as  defined  by  the 
designated  approval  authority  at  each  anticipated  deployment  site. 
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The  system  must  meet  all  security  and  TEMPEST  requirements  for  interoperability  with 
theater  and  national  command  and  control  C4I  systems  and  must  be  able  to  interchange  data 
with  these  systems  in  DoD  standard  formats. 

JSIMS  must  protect  classified  data  through  concepts  integrated  into  system  hardware  and 
software  as  part  of  the  architecture  for  storing,  retrieving  and  passing  data  between 
processes.  External  protective  devices  may  be  used  but  the  integration  of  security  safeguards 
into  the  hardware  and  software  is  preferred. 

(e)  Training  Environment: 

Training  exercises  are  developed  to  provide  conditions  as  close  as  possible  to  those  of 
real-world  operations.  JSIMS  supported  exercises  must  provide  a  training  environment  that 
approaches  actual  operational  conditions  for  the  participating  battle  staff(s).  Exercise 
participants  should  not  be  able  to  distinguish  between  real  and  simulated  entities.  Exercise 
participants  should  interact  with  simulated  entities  provided  by  JSIMS  using  the  same  C4I 
systems,  processes,  and  procedures  they  would  normally  use.  However,  necessary 
safeguards  must  be  present  in  the  system  to  avoid  confusion  with  real-world  events  and 
permit  orderly  transition  from  exercise  to  real-  world  operations. 

(f)  Scenario  Generation: 

A  scenario  generation  capability  must  be  provided  to  rapidly  create  and  modify  scenarios 
via  a  graphical  user  interface  capability.  The  scenario  generation  capability  must  include  the 
ability  to  create,  review,  and  modify  data  sets  that  contain  data  pertinent  to  the  exercise  such 
as:  information  on  the  natural,  physical  environment  (land,  ocean,  atmosphere,  and  space), 
friendly  unit  information,  opposing  forces  information,  exercise  control  information,  rules 
of  engagement  (ROE),  etc.  The  data  sets  must  be  built  in  an  automated,  efficient  manner 
from  approved  certified  DoD  data  sources. 

JSIMS  must  have  the  ability  to  modify  the  training  environment  by  manipulating  scenarios, 
adding  or  replacing  models  and  simulations,  modifying  doctrinal  representations,  changing 
system  parameters,  allowing  for  multiple  level  resolution  and  varying  levels  of  fidelity, 
adding  and  deleting  workstations,  reconfiguring  workstation  functionality,  and  controlling 
an  exercise  (e.g.,  starting,  stopping,  etc.). 

(g)  Interfaces: 

JSIMS  must  interact  directly  with  the  training  audience  through  operational  C4I  systems 
while  communicating  in  a  format  that  is  transparent  to  the  user  in  terms  of  distinguishing 
between  real  and  simulated  participants.  JSIMS  must  provide  the  mechanism  to  interface 
with  appropriate  Joint  and  Service  C4I  systems,  such  as  Global  Command  and  Control 
System  (GCCS),  Standard  Theater  Army  Command  and  Control  System  (STACCS),  Joint 
Maritime  Command  Information  System  (JMCIS),  Contingency  Theater  Automated 
Planning  System  (CTAPS),  Special  Operations  Forces  Planning  and  Rehearsal  System 
(SOFPARS),  and  Consolidated  Aerial  Port  system  (CAPS). 

JSIMS  must  have  the  capability  to  interoperate  with  live,  virtual,  and  constructive  HE  A 
compliant  models  and  simulations  developed  independently  of  JSIMS. 

(h)  Data  Support: 

JSIMS  must  use  standardized  data  elements  to  facilitate  interchange  of  data  between  JSIMS, 
external  simulations  and  real  C4I  systems.  Data  standardization  vdll  be  consistent  with  DoD 
guidelines  and  data  sets  must  be  from  certified  DoD  data  sources. 
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Tools  and  utilities  must  be  provided  to  import  and  export  standard  formatted  files  (e.g., 

Time  Phased  Force  and  Deployment  List  (TPFDL)  and  Air  Tasking  Order  (ATO))  in  order 
to  create  efficient  information  exchange  among  simulation  databases. 

(i)  Human-in-the-Loop  (HITL): 

JSIMS  must  allow  for  the  HITL,  even  if  the  procedure  can  be  executed  automatically. 

JSIMS  must  provide  HITL  capability  with  all  simulations  executing  concurrently,  including 
those  above  and  below  the  main  user  level  (i.e.,  echelon  of  command)  of  the  simulation 
being  played.  JSIMS  must  provide  for  HITL  with  computer  generated  forces  (CGF) 
representing  friendly,  neutral,  and  opposing  forces.  JSIMS  will  provide  the  ability  to 
combine  and  switch  between  HITL  and  semi-automated  forces  during  execution. 

(j)  Simulation  of  Human  Performance  Factors: 

JSIMS  must  support  adjustment  to  unit/human  effectiveness  due  to  combat  experience, 
level  of  training,  social,  religious,  morale,  weather,  nutrition,  sleep  deprivation,  and  political 
influences. 

JSIMS  must  support  adjustment  to  human  performance  due  to  conditions  contained  in  the 
current  version  of  the  Universal  Joint  Task  List  published  by  the  Joint  Staff  (JSM  3500.04). 

JSIMS  must  be  able  to  cause  simulated  entities  to  "make  mistakes"  based  on  factors  such  as: 
level  of  training,  misperceptions  of  the  operational  situation,  fatigue,  or  reduced  combat 
effectiveness. 

(k)  Multi-sided  Play: 

JSIMS  must  support  a  variable  number  of  sides  including  US  forces,  US  allies,  enemy 
jforces,  enemy  allies,  and  neutral  forces.  JSIMS  must  be  able  to  support  allegiance  changes 
during  execution.  Forces  must  have  the  capability  to  change  sides  during  the  exercise. 
JSIMS  must  also  be  able  to  support  alliance  or  coalition  realignment. 

(l)  Scaling  Factors: 

JSIMS  must  be  able  to  accommodate  exercises  where  different  scales  of  simulation  are 
interacting  with  one  another.  For  example,  a  high-resolution  entity-level  virtual  simulation 
could  be  linked  to  an  aggregate  level  constructive  simulation. 

(m)  Fidelity: 

Fidelity  refers  to  the  degree  of  accuracy  with  which  JSIMS  must  represent  actual 
environmental  activities.  JSIMS  must  allow  for  variable  degrees  of  fidelity.  High  fidelity 
simulation  is  required  for  realistic  interactions  at  the  entity  level. 

(n)  Level  of  Resolution/Aggregation: 

JSIMS  must  be  able  to  portray  variable  levels  of  detail  in  accordance  with  training 
requirements  as  defined  by  tasks  in  the  current  version  of  the  Universal  Joint  Task  List 
published  by  the  Joint  Staff  (JSM  3500.04).  It  must  be  able  to  aggregate  tactical  entities 
(e.g.,  battalion,  squadron,  battle  group)  appropriate  to  the  exercise  or  portray  events  down  to 
the  effects  of  individual  Service  entities  (e.g.,  tanks,  aircraft,  warfighter).  TTie  level  of  detail 
required  will  be  dictated  by  the  scenario  being  executed.  National  and  tactical  intelligence 
data  must  be  provided  in  appropriate  detail,  format,  and  method  of  transmission  with 
realistic  timeliness. 

JSIMS  must  generate  appropriately  detailed  results  for  each  level  of  play.  Aggregation  of 
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entities  into  larger  groupings  (variable  resolution)  with  scaleable  terrain  must  be  available  to 
reduce  overhead  without  a  loss  of  fidelity.  Resolution  will  increase  as  requirements  for 
training  lower  unit  echelons[JTSS]  are  incorporated.  For  higher  level  training  (where  only 
senior  staffs  are  involved),  the  system  will  aggregate  data  as  required  to  present  results  to 
the  players  in  a  useable  format.  When  training  lower  levels,  the  system  must  simulate  the 
echelon  directives  in  a  realistic  manner.  [JTSS] 

(o)  Simulation  Time: 

Simulation  time  must  be  controllable  within  a  range  from  slower  than  real-time  to 
substantially  faster  than  real-time  to  support  accelerated  execution  replay,  fast  forward,  and 
after  action  review  (AAR)  functions.  The  goal  is  to  support  simulation  execution  rates  on 
the  order  of  1 :10  (slow  time)  up  to  100:1  (fast  time).  Simulation  time  must  include  event 
driven  step  synchronous,  event  driven  step  asynchronous,  and  time  driven  step  (real  and 
clock)  options.  This  will  provide  end  users  with  the  capability  to  support  a  wider  variety  of 
mission  taskings. 

(p)  Exercise  Control  and  Players: 

Exercise  control  addresses  the  simulation  control  and  system  control  required  to  ensure  the 
simulation  operates  to  satisfy  the  training  requirements.  JSIMS  operation  must  be  user 
friendly  so  that  learning  to  operate  the  system  is  simplified.  Ideally,  not  more  than  24  hours 
of  training  will  be  required  to  train  new  controllers,  role  players,  and  response  cell 
personnel.  The  number  of  exercise  controllers  required  will  vary  according  to  the 
human-in-the-loop  requirements  of  the  particular  exercise,  test  or  training  activity. 
(Significant  reduction  in  the  number  of  support  personnel  to  conduct  training  and  exercises 
is  a  primary  objective  of  JSIMS.  At  IOC,  the  goal  is  to  reduce  the  support  personnel 
overhead  by  at  least  two  thirds  of  what  is  required  to  conduct  an  ALSP  supported  JTF  level 
exercise  in  1995). 

(i)  Exercise  Controller  Privileges: 

(a)  JSIMS  exercise  controllers  must  have  the  ability  to  start,  freeze,  stop,  fast  forward, 
restart,  shutdown,  take  a  snapshot  of  all  data  in  the  system,  record  selected  events,  select  the 
time  scale  in  which  to  operate,  vary  game  speed,  and  manage  system  configuration  (i.e., 
distributed,  single  site).  A  restart/replay  fimction  must  be  present  for  AAR,  debrief,  and 
exploration  of  alternative  courses  of  action. 

(b)  The  exercise  controllers  must  have  the  ability  to  modify  the  status  of  simulated  units, 
equipment,  features,  and  event  outcomes.  For  example,  controllers  need  the  ability  to 
relocate  units,  resupply  units,  restore  equipment,  disable  equipment,  change  the  damage 
status  of  roads,  bridges,  airfields,  etc. 

(ii)  Player  Privileges: 

The  player  only  has  the  ability  to  make  limited  modifications  to  his  side's  data  consistent 
with  actual  operational  capabilities.  Any  additional  capabilities  will  be  assigned  by  the 
controller  on  an  as  needed  basis. 

(iii)  Semi- Automated  Controllers: 

JSIMS  must  provide  the  capability  to  incrementally  automate  many  of  the  manpower 
intensive  control  functions  typical  to  existing  simulations  throughout  the  exercise  time 
frame:  planning,  scenario  generation  (intelligent  laydown  of  friendly  and  opposing  forces), 
execution  (knowledge-based  order  validation),  and  after  action  review  (data  capture  for 
playback  of  key  events). 
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(q)  Ground  Truth: 

Display  information  depicting  ground  truth  will  be  maintained  as  a  separate  function  for  use 
by  exercise  controllers  as  opposed  to  the  perceived  or  reported  truth  available  to  exercise 
participants.  Even  when  all  the  opposing  sides  are  simulated,  the  opposing  commanders' 
actions  must  be  based  on  a  less  than  perfect  perception  of  the  battlefield  rather  than  ground 
truth.  The  simulation  must  have  the  ability  to  track  and  compare  a  side's  perception  versus 
ground  truth. 

(r)  After  Action  Review  (AAR): 

JSIMS  must  provide  an  AAR  capability  to  assess  the  performance  of  participants  in  a 
training  exercise  as  well  as  provide  rapid  feedback  to  the  exercise  sponsor  on  the  attainment 
of  exercise  objectives.  JSIMS  will  provide  the  capability  to  record  user  specified  events  and 
data,  to  respond  to  specific  queries  regarding  the  exercise,  and  to  provide  information  in 
various  formats  while  the  simulation  continues  to  execute.  It  is  important  to  emphasize  that 
data  extraction  must  be  a  continuously  available  process  to  support  real-time  updates.  As  an 
example,  a  three  person  team  of  AAR  analysts  must  be  able  to  collate  a  daily  status  report 
for  presentation  to  the  exercise  sponsor  in  less  than  two  hours.  A  team  of  six  analysts  should 
be  able  to  present  a  "hot  wash"  type  briefing  to  the  training  audience  fi-om  previously 
extracted  and  archived  data  within  three  hours  of  the  training  event  conclusion. 

AAR  formats  include,  but  are  not  limited  to,  the  following:  three  dimensional  graphical 
displays  on  a  portable  screen,  printouts  and  overhead  view  graphs  of  data  (overlaid  on  maps 
when  applicable),  statistical  graphs  of  data,  tabular  outputs  of  data  as  well  as  text  messages. 
JSIMS  must  be  able  to  track  special  or  high  interest  information,  provide  automatic 
detection  of  events  based  upon  common  errors,  and  to  compare  recorded  ground  truth 
information  with  the  recorded  player  perspective.  The  AAR  capability  must  allow  the 
operator  to  modify  existing  output  formats  or  build  new  displays  to  support  debrief  and 
review  of  data.  The  AAR  capability  should  allow  for  playback  of  the  exercise  events  in 
real-time  and  accelerated  modes.  Two  dimensional  and  three  dimensional  views  of  the 
battlefield  are  required.  A  capability  to  attach  to  individual  units  or  components  during 
playback  would  be  desired  to  view  the  battle  from  that  unit's  perspective.  The  AAR 
capability  must  provide  the  operator  with  a  set  of  statistical  analysis  tools. 

(s)  Report  Generation: 

JSIMS  must  include  a  capability  to  generate  formatted  and  freeform  (text)  reports  for  both 
players  and  exercise  controllers.  This  function  must  provide  the  user  with  a  wide  range  of 
automatic  reports  that  would  be  expected  if  actual  units  were  represented  in  exercise 
scenarios.  [US AF]  The  report  generation  capabilities  should  include:  the  ability  to  create  and 
modify  user  defined  reports,  the  ability  to  automatically  generate  reports  based  upon  events 
or  time,  and  the  ability  to  tailor  the  report  format.  The  tailoring  of  the  report  output  formats 
must  support  the  ability  to  produce  reports  in  the  appropriate  formats  so  that  they  can  be 
transmitted  through  real-world  message  formats. 

(3)  Analysis  Requirements 

JSIMS  is  not  an  analytical  tool.  However,  it  will  be  interoperable  with  emerging  analysis 
tools  such  as  the  Joint  Warfare  System  (JWARS)  in  accordance  with  the  DoD-wide 
Technical  Framework  for  M&S.  During  joint  training  exercises,  issues  such  as  Course  of 
Action  (COA)  development  and  assessment,  force  on  force  assessments,  and  the  evaluation 
of  Time  Phased  Force  Deployment  Data  (TPFDD)  for  impact  on  mobilization,  and 
sustainment  of  forces,  all  play  a  key  part  in  the  JTF  Commander's  decision  process. 
Capturing  dynamic,  operationally  valid  scenarios  to  explore  these  issues  can  be  the  basis  for 
realistic  analyses.  JSIMS  scenarios  and  data  must  be  interchangeable  with  analysis  models 
to  the  maximum  extent  possible  to  achieve  this  flexibility. 
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b.  Logistics  and  Readiness< 

(1)  Reliability  and  Availability  (R&A) 

JSIMS  must  be  capable  of  operating  24  hours  a  day  with  a  system  availability  of  at  least  95%. 
Availability  is  defined,  in  this  instance,  as  all  components  of  the  system  being  operated  at 
technical  control  designated  speeds,  including  pausing  or  shut  down  of  selected  components,  with 
the  system  continuing  to  process  data  normally.  JSIMS  will  be  required  to  support  training 
exercises  whose  duration  ranges  from  1  to  30  days,  24  hours  per  day.  A  significant  goal  is  for  the 
system  to  be  capable  of  restarting  no  more  than  one  hour  after  correction  of  a  full  system  failure 
from  the  point  of  failure. 

(2)  Setup/Breakdown 

In  general,  JSIMS  hardware  will  use  COTS  products  wherever  feasible.  The  system 
components  will  be  plug  and  play  to  the  maximum  extent  possible  to  allow  for  rapid  setup 
and  configuration. 

c.  Critical  System  Characteristics 

The  normal  operating  environment  for  JSIMS  hardware  will  be  in  existing  Simulation, 
Training,  and  Command  and  Control  Centers.  Adherence  to  industry  standards  for  power 
consumption,  temperature  and  humidity  conditions,  and  reduction  of  electromagnetic 
interference  is  required.  JSIMS  components  do  not  have  to  be  capable  of  operating  in 
hostile  nuclear,  chemical,  or  electronic  environments. 

5.  Integrated  Logistics  Support  (ILS) 

a.  Maintenance  Planning 

JSIMS  must  make  use  of  modular  design  and  component  technology  which  supports  the 
integration  of  new  hardware  and  software  modules  and  substitution  of  compatible  hardware 
to  embrace  the  pace  of  technology.  Nothing  in  the  maintenance  concept  will  preclude  wide 
use  of  a  cost-effective,  expendable  hardware  spares  inventory  as  ready  line  replaceable  units 
(LRUs)  for  low  to  moderate  cost  components.  Maintenance  will  be  conducted  using  existing 
DoD  maintenance  structures,  procedures,  and  best  commercial  practices.  Costs  must  be 
considered  in  determining  repair  capabilities  but  should  not  override  mission  requirements. 

(1)  Hardware  Organizational  Maintenance 

Equipment  maintenance  at  the  organization  level  will  be  performed  by  either  milit^, 
civilian,  or  contractor  maintenance  technicians.  The  contractor's  repair  level  analysis  will 
identify  items  of  equipment,  modules,  etc.  for  repair  and  determine  their  repair  location. 

(2)  Software  Maintenance 

(a)  Performance  Logging  and  Post-deployment  Software  Support  (PDSS) 

A  system  which  supports  the  functions  of  modem  Computer  Aided  Software  Engineering 
(CASE)  tools,  such  as,  debugging  support,  error  tracking,  failure  logging,  and  reliability 
estimation,  will  exist  to  support  the  correction  of  errors  in  the  software  design  and 
implementation.  This  capability  should  support  the  design,  build,  test  and  operational 
phases  of  the  system  implementation. 

(b)  Maintenance  Responsibility 
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Software  maintenance  will  be  conducted  by  the  Service  component  or  federal  agent  who  is 
the  recognized  controller  of  the  portion  of  the  software  system  or  module  which  represents 
the  warfighting  subspecialty  which  fails  to  fimction  properly.  The  method  of  integration  and 
testing  of  new  code  at  the  JSIMS  program  level  will  concentrate  on  integration  actions 
necessary  to  for  the  successful  operation  of  the  whole  system. 

(i)  Software  maintenance  concepts  will  be  compatible  with  existing  Service  and  DoD 
instructions  and  will  support  the  use  of  modem  CASE  tools  for  organization  of  actions, 
tracking  and  documentation. 

(ii) .  Strict  version  control  will  be  required  of  all  offered  portions  of  software  systems  or 
modules.  Accepted,  integrated  versions  will  be  formally  qualified,  by  a  standardized 
procedure,  for  use  as  a  component  of  JSIMS. 

b.  Support  Equipment 

Support  equipment  for  maintenance  will  be  kept  to  a  minimum  and  the  system  will  be 
designed  to  be  maintained  by  standard  test  equipment  and  will  include  fault  isolation 
capabilities  to  diagnose  failures  at  a  level  commensurate  with  the  final  support  concept.  The 
system  will  be  designed  to  maximize  the  use  of  BIT  (Built-in  Test),  BITE  ^uilt-in  Test 
Equipment),  and  resident  and/or  loaded  diagnostic  software  to  isolate  to  the  line  replaceable 
unit  level. 

c.  Human  Systems  Integration 

(1)  Human  Computer  Interface  (HCI) 

Modem  HCI  concepts  accommodating  novice  through  expert  operators  must  be  used  in  the 
architecture  of  JSIMS  to  reduce  the  need  for  training  at  the  computer  operating  system 
level,  especially  for  response  cell  players  and  technical  controllers.  Reduction  in  the  need 
for  training  through  use  of  "point  and  click"  and  other  interfaces,  with  on-line  help  screens 
is  a  goal  of  the  system.  As  part  of  training,  the  contractor  will  provide  tutorials,  on-line 
references,  manuals,  and  "help  screens,"  to  include  all  system  configuration  operations  and 
operator  maintenance. 

(2)  Manpower  Support 

JSIMS  should  be  developed  to  allow  fielding  within  the  current  or  reduced  manpower 
constraints.  An  integrated  manpower,  personnel,  and  comprehensive  training  and  safety 
planning  team  will  be  formed.  This  team  will  be  responsible  for  documenting  all  manpower 
requirements,  addressing  manpower  funding,  and  developing  complete  Manpower  Estimate 
Reports. 

d.  Computer  Resources 

(1)  Open  System  Architecture  and  Standards 

JSIMS  will  be  developed  in  an  open  system  environment  architecture  to  allow  the 
portability  of  applications  between  heterogeneous  hardware  suites  and  to  facilitate 
interoperability  with  Service-level  systems  and  other  existing  and/or  future  systems.  To 
facilitate  software  portability  to  existing,  planned  and  future  hardware  suites,  all  software 
will  be  developed  in  compliance  with  open  system  software  standards.  Existing 
documented,  maintainable,  portable,  government  off-the-shelf(GOTS),  or  commercial 
off-the-shelf  (COTS)  software  packages  will  be  used  to  the  maximum  extent  possible  to 
satisfy  identified  requirements  before  dedicating  resources  to  developing  major  system 
enhancements  or  new  application  components. 
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JSIMS  workstations  must  be  consistent  with  an  open  system  environment  architecture. 
JSIMS  must  be  hardware  platform  independent  and,  where  technically  feasible,  must  allow 
the  computers  already  existing  at  each  command  to  be  used.  Lack  of  specialized  hardware  at 
any  location  should  not  preclude  active  participation.  The  JSIMS  design  must  facilitate  the 
migration  to  improved  workstations  as  they  become  available.  [NASM,  WARSIM  ORD] 

(2)  Software 

JSIMS  will  be  designed  for  portability  and  reusability  in  a  modem,  standards  based, 
supportable  programming  language  using  modem  programming  techniques  and  CASE  tools 
where  appropriate.  [TRD,  5.7]  Existing  DoD  and  COTS  products  andNDIs,  as  appropriate, 
will  be  used  to  the  maximum  extent  possible  within  the  constraints  of  the  life  cycle 
maintenance  to  reduce  manpower  and  other  support  resources  and  permit  ready 
technological  upgrades.  Quality,  non-proprietary  software  documentation  and  source  code 
that  facilitates  software  maintenance  will  be  developed  and  delivered.  [WARSIM  ORD, 

TRD  5.7] 

Developed  software  will  be  modular  so  that  the  software  can  be  changed  and  improved 
without  affecting  the  design  of  other  modules.  The  system  will  be  developed  with  growth  in 
mind.  The  software  ^vill  employ  error  management  aids  and  permit  users  to  obtain  on-line 
guidance  by  requesting  help  screens.  Following  the  output  of  an  error  message,  users  should 
be  permitted  to  request  additional  information  at  levels  of  increasing  detail.  JSIMS  will  be 
designed  such  that  all  data  (i.e.,  parameters  of  the  models,  mles  for  expert  systems, 
addresses  for  network  nodes)  are  not  hard-coded  into  the  software.  JSIMS  will  provide  the 
flexibility  to  change  system  parameters,  rules,  network  configuration  without  disruption  to 
an  exercise.  [WARSIM  ORD]  JSIMS  must  include  system  and  software  documentation 
adequate  to  support  PDSS,  training,  and  operation.  In  addition  to  hardcopy,  the  JSIMS 
documentation  must  be  provided  in  digital  form  for  on-line  access. 

(3)  Configuration  Management 

Each  Service  organization  will  be  responsible  for  providing  inputs  relating  to  unique  site 
requirements  to  the  configuration  control  board  (CCB)  for  approval  and  through  a  Software 
Support  Facility  (SSF)  for  execution. 

6.  Infrastructure  Support  And  Interoperability 

a.  Command,  Control,  Communications,  Computers,  and  Intelligence  (C4I) 

JSIMS  must  interface,  to  the  maximum  extent  possible,  with  existing  C4I  equipment  that 
supports  the  the  Unified  Combatant  Commanders,  JTF  Commander,  Joint  Component 
Commanders  and  their  staffs,  as  well  as  other  JSIMS  users.  This  includes  data,  voice,  and 
video  for  target  planning,  mission  planning,  intelligence,  and  communications  activities. 

b.  Transportation  and  Basing 

Existing  Simulation  Centers,  Training  Sites,  and  Command  Centers  are  plaimed  as  primary 
host  sites  for  JSIMS. 

d.  Mapping,  Charting,  and  Geodesy  Support 

JSIMS  will  use  standardized  terrain  databases  to  facilitate  interoperability  with  other 
systems  and  reduce  costs.  JSIMS  has  the  goal  of  using  terrain  representations  of  the  highest 
resolution,  or  most  complete  detail,  which  can  be  supported  by  the  speed  of  operation  of  the 
host  computer  and  remote  terminal  equipment  which  best  fit  the  system  design  architecture. 
As  the  M&S  Executive  Agent  for  Terrain,  the  Defense  Mapping  Agency  (DMA)  will 
provide  terrain  database  standards,  if  available,  or  will  establish  new  standards. 
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7.  Force  Structure 

The  number  of  operational  systems,  subsystems,  spares,  and  training  units  is  TBD.[LHR1] 

8.  Schedule  Considerations 

JSIMS  IOC  is  defined  as  the  deployment  of  a  system  that  provides  the  initial  population  of 
the  JSIMS  architecture  with  facilities,  services,  and  tools  to  provide  for  JTF  and  Service 
training.  JSIMS  IOC  will  provide  a  fhnctional  replacement  for  the  ALSP  confederation  of 
models.  JSIMS  FOC  will  provide  the  Unified  Combatant  Commands,  Services,  and  other 
users  a  distributed,  integrated  system  capable  of  supporting  the  full  range  of  missions  and 
operations,  including  OOTW. 
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AAR 

ADS 

ALSP 

ARPA 

ATO 

AWSIM 

BIT 

BITE 

C4I 

CAP 

CAPS 

CASE 

CBS 

CCB 

CGF 

CINC 

COA 

CONUS 

COTS 

CSSTSS 

CTAPS 

DMA 

DMSO 

DMSP 

DoD 

FOC 

GCCS 

GOTS 

HCI 

HITL 

ILS 


After  Action  Review 

Advanced  Distributed  Simulation 

Aggregate  Level  Simulation  Protocol 

Advanced  Research  Project  Agency 

Air  Tasking  Order 

Air  Warfare  Simulation 

Built-in  test 

Built-in  test  equipment 

Command,  Control,  Communications,  Computers,  and 
Intelligence 

Crisis  Action  Procedures 
Consolidated  Aerial  Port  System 
Computer  Aided  Software  Engineering 
Corps  Battle  Simulation 
Configuration  Control  Board 
Computer  Generated  Forces 
Commander  in  Chief 
Course  of  action 
Continental  United  States 
Commercial  off-  the-  shelf 

Combined  Service  Support  Training  Simulation  System 

Contingency  Theater  Automated  Planning  System 

Defense  Mapping  Agency 

Defense  Modeling  and  Simulation  Office 

Defense  Meteorological  Satellite  Program 

Department  of  Defense 

Full  Operational  Capability 

Global  Command  and  Control  System 

Government  off-the-shelf 

Human  Computer  Interface 

Human- in-the-loop 

Integrated  Logistics  Support 
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INFOSEC  Information  Security 

IOC  Initial  Operational  Capability 

JECEWSI  Joint  Electronic  Combat-Electronic  Warfare  Simulation 

JMCIS  Joint  Maritime  Command  Information  System 

JMET  Joint  Mission  Essential  Task 

JMET  Joint  Mission  Essential  Task  List 

JPO  Joint  Program  Office 

JSIMS  Joint  Simulation  System 

JTF  Joint  Task  Force 

JWARS  Joint  Warfare  System 

LRU  Line  Replaceable  Unit 

M&S  Modeling  and  Simulation 

MAGTF  Marine  Air  to  Ground  Task  Force 

MTWS  MAGTF  Tactical  Warfare  Simulation 

MNS  Mission  Needs  Statement 

MOA  Memorandum  of  Agreement 

NDI  Non-developmental  Item 

OOTW  Operations  Other  than  War 

OPFOR  Opposing  Forces 

ORD  Operational  Requirements  Document 

OT&E  Operational  Test  and  Evaluation 

RESA  Research  Evaluation  and  Systems  Analysis  Simulation 

PDSS  Post  Deployment  Software  Support 

ROE  Rules  of  Engagement 

SCI  Sensitive  Compartmented  Information 

SOF  Special  Operations  Forces 

SOFPARS  Special  Operations  Forces  Planning  and  Rehearsal  System 
SSF  Software  Support  Facility 

STACCS  Standard  Theater  Army  Command  and  Control  System 

STOW  Synthetic  Theater  of  War 

T&E  Test  and  Evaluation 

TACSIM  Tactical  Simulation  Model 

TBD  To  be  determined 

TPFDD  Time  Phased  Force  and  Deployment  Data 

TPFDL  Time  Phased  Force  and  Deployment  List 

TRANSCOM  Transportation  Command 
US  United  States 

VV&A  Verification,  Validation  and  Accreditation 

VV&C  Verification,  Validation,  and  Certification 


Annex  C 

Executive  Summary 

The  mission  of  the  Joint  Simulation  System  (JSIMS)  is  to  provide  a  readily  available, 
operationally  valid  synthetic  environment  for  the  Commanders  in  Chiefs  (CINCs),  their 
components,  other  Joint  organizations  and  the  Services  to:  jointly  train,  educate,  develop 
doctrine  and  tactics,  formulate  and  assess  operational  plans,  assess  warfighting  situations, 
define  operational  requirements,  and  provide  operational  input  to  the  acquisition  process.  In 
short,  JSIMS  will  provide  not  only  an  improved  capability  for  inter-Service  operability  but 
also  an  enhanced  Joint  battle  staff  training  capability  for  the  warfighting  CINCs. 

The  Joint  Simulation  System  (JSIMS)  will  be  a  core  of  common  and  joint  represeritations 
and  services,  a  run-time  hardware  and  software  infrastructure,  and  interfaces,  that  is 
augmented  by  the  representations  of  Air/Space,  Land,  and  Sea  Warfare  functionality.  The 
representations  of  Air/Space,  Land,  and  Sea  Warfare  functionality  will  be  provided  via 
sponsorship  by  Executive  Agents.  In  keeping  with  the  premise  that  the  Services/components 
are  best  able  to  define  their  own  capabilities  and  functionality,  the  Joint  Program  Office 
(JPO)  will  work  in  concert  with  the  Services  through  the  Executive  Agents  to  import 
Service-provided  functionality  such  as  land,  air,  naval  and  littoral  warfare  into  JSIMS.  The 
JPO  will  integrate  these  fiinctionalities  for  use  by  Joint  battle  staffs  and  by  others  wishing  to 
inter-operate  with  one  or  more  of  the  other  Services,  e.g.,  an  Army/Air  Force  exercise. 
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JSIMS  development  will  be  incremental,  marked  by  two  key  events:  Initial  Operational 
Capability  (IOC),  and  Full  Operational  Capability  (FOC). 

The  JSIMS  Operational  Requirements  Document  (ORD)  is  a  programmatic  document 
which  details  the  users'  expectations  of  the  functionality  of  the  simulation  system.  It 
attempts  to  characterize  the  important  aspects  of  the  program  without  precluding  the  use  of 
emerging  technology.  After  In  preparation  for  Milestone  II  is  achieved  review,  the 
Operational  Requirements  Document  will  be  updated  and  expanded  in  accordance  with  the 
provisions  of  reference  (e).  At  that  time,  more  specific  performance  thresholds  will  be 
included  based  on  the  results  of  initial  testing  and  prototyping  efforts. 

Annex  D 
Glossary 

The  following  definitions  were  extracted  from  reference  (b):  DoD  Directive  5000.59-Paa, 
DoD  Modeling  and  Simulation  Master  Plan  and  reference  (f):  draft  DoD  Glossary  of  M  &S 
Terms.  The  sources  for  the  definitions  in  this  glossary  have  not  been  included.  The  sources 
are  available  in  the  reference  documents. 

Accreditation.  The  official  certification  that  a  model  or  simulation  is  acceptable  for  use  for  a 
specific  purpose. 

Advanced  Distributed  Simulation  (ADS).  A  set  of  disparate  models  or  simulations  operating 
in  a  common  synthetic  environment  in  accordance  with  the  Distributed  Interactive 
Simulation  (DIS)  standards.  The  ADS  may  be  composed  of  three  modes  of  simulation:  live, 
virtual  and  constructive  which  can  be  seamlessly  integrated  within  a  single  exercise.  See 
also:  live  simulation;  virtual  simulation;  constructive  simulation. 

Aggregate  Level  Simulation  Protocol  (ALSP).  A  family  of  simulation  interface  protocols 
and  supporting  infrastructure  software  that  permit  the  integration  of  distinct  simulations  and 
wargames.  Combined,  the  interface  protocols  and  software  enable  large-scale,  distributed 
simulations  and  wargames  of  different  domains  to  interact  at  the  combat  object  and  event 
level.  The  most  widely  known  example  of  an  ALSP  confederation  is  the  Joint/Service 
Training  Confederation  (CBS,  AWSIM,  RESA,  TACSIM,  CSSTSS)  which  has  provided 
the  bac&)one  to  many  large,  distributed,  simulation-supported  exercises.  Other  examples  of 
ALSP  confederations  include  confederations  of  analytical  models  that  have  been  formed  to 
support  US  Air  Force,  US  Army,  and  US  TRANSCOM  studies.  (Aggregate  Level 
Simulation  Protocol  Technical  Specification,  July  1992)  Note:  JECEWSI  and  MTWS  are 
also  now  included  in  the  1995  ALSP  Confederation 

Aggregation.  The  ability  to  group  entities  while  preserving  the  effects  of  entity  behavior  and 
interaction  while  grouped.  (See  also  definition  of  disaggregation.) 

Architecture.  An  architecture  is  the  structure  of  components  in  a  program/system,  their 
interrelationships,  and  principles  and  guidelines  governing  their  design  and  evolution  over 
time. 

Authoritative  Representation.  Authoritative  representations  are  models,  algorithms,  and  data 
that  have  been  developed  or  approved  by  a  source  which  has  accurate  technical  knowledge 
of  the  entity  or  phenomenon  to  be  modeled  and  its  effects. 

Battlespace.  Battlespace  refers  both  to  the  physical  environment  in  which  the  simulated 
warfare  will  take  place  and  the  forces  that  will  conduct  the  simulated  warfare.  All  elements 
which  support  the  front  line  forces  (e.g.,  logistics,  intelligence)  are  included  in  this 
definition  of  battlespace. 

Combatant  Command  (s).  One  of  the  unified  or  specified  combatant  commands  established 
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by  the  President  of  the  United  States.  (Combatant  Commands  currently  include:  US  Atlantic 
Command  (USACOM);  US  Central  Command  (USCENTCOM);  US  European  Command 
(USEUCOM);  US  Pacific  Command  (USPACOM);  US  Southern  Command 
(USSOUTHCOM);  US  Space  Command  (USSPACOM);  US  Special  Operations  Command 
^SSOCOM);  US  Strategic  Command  (USSTRATCOM);  and,  US  Transportation 
Command  (USTRANSCOM)). 

Computer  Generated  Forces  (CGF).  A  generic  term  used  to  refer  to  computer 
representations  of  forces  in  simulations  which  attempts  to  model  human  behavior 
sufficiently  so  that  the  forces  will  take  some  actions  automatically  (without  requiring 
man-in-the-loop  interaction).  Also  referred  to  as  Semi-automated  Forces  (SAFOR). 

Computer  Simulation.  A  dynamic  representation  of  a  model,  often  involving  some 
combination  of  executing  code,  control/display  interface  hardware,  and  interfaces  to 
real-world  equipment. 

Data.  A  representation  of  facts,  concepts,  or  instructions  in  a  formalized  manner  suitable  for 
communication,  interpretation,  or  processing  by  humans  or  by  automatic  means. 

Data  Certification.  The  determination  that  data  have  been  verified  and  validated.  Data  user 
certification  is  the  determination  by  the  application  sponsor  or  designated  agent  that  data 
have  been  verified  and  validated  as  appropriate  for  the  specific  M&S  usage.  Data  producer 
certification  is  the  determination  by  the  data  producer  that  data  have  been  verified  and 
validated  against  documented  standards  or  criteria. 

Data  Exchange  Standard.  Formally  defined  protocols  for  the  format  and  content  of  data 
messages  used  for  interchanging  data  between  networked  simulation  and/or  simulator  nodes 
used  to  create  and  operate  a  distributed,  time  and  space  coherent  synthetic  environment. 
Current  standards  are  ALSP  and  DIS  PDUs. 

Data  Standardization.  The  process  of  documenting,  reviewing,  and  approving  unique  names, 
definitions,  characteristies  and  representations  of  data  aecording  to  established  proeedures 
and  conventions. 

Data  Validation.  The  documented  assessment  of  data  by  subject  area  experts  and  its 
comparison  to  known  values.  Data  user  validation  is  an  assessment  as  appropriate  for  use  in 
an  intended  model.  Data  producer  validation  is  an  assessment  within  stated  criteria  and 
assumptions. 

Data  Verification.  Data  producer  verification  is  the  use  of  techniques  and  procedures  to 
ensure  that  data  meets  constraints  defined  by  data  standards  and  business  rules  derived  from 
process  and  data  modeling.  Data  user  verification  is  the  use  of  techniques  and  procedures  to 
ensure  that  data  meets  user  specified  constraints  defined  by  data  standards  and  business 
rules  derived  from  process  and  data  modeling,  and  that  data  are  transformed  and  formatted 
properly. 

Data  Verification,  Validation,  &  Certification  (VV&C).  The  process  of  verifying  the 
internal  consistency  and  correctness  of  data,  validating  that  it  represents  real-world  entities 
appropriate  for  its  intended  purpose  or  an  expected  range  of  purposes,  and  certifying  it  as 
having  a  specified  level  of  quality  or  as  being  appropriate  for  a  specified  use,  type  of  use,  or 
range  of  uses.  The  process  has  two  perspectives:  producer  and  user  proeess. 

Disaggregation.  The  ability  to  represent  the  behavior  of  an  ag^egated  unit  in  terms  of  its 
component  entities.  If  the  aggregate  representation  did  not  maintain  state  representations  of 
the  individual  entities,  then  the  decomposition  into  the  entities  can  only  be  notional. 

Environment.  The  texture  or  detail  of  the  domain,  that  is  terrain  relief,  weather,  day,  night. 


17  of  22 


Operational  Requirements  Document 


terrain  cultural  features  (such  as  cities  or  farmland),  sea  states,  etc.);  (2)  the  external  objects, 
conditions,  and  processes  that  influence  the  behavior  of  a  system  (such  as  terrain  relief, 
weather,  day/night,  terrain  cultural  features,  etc.). 

Environmental  Representation.  An  authoritative  representation  of  all  or  a  part  of  the  natural 
or  man-made  environment. 

Extensibility.  The  ability  of  a  data  structure  to  accommodate  additional  values  or  iterations 
of  data  over  time  without  impacting  its  initial  design. 

Fast  Time.  (1)  Simulated  time  with  the  property  that  a  given  period  of  actual  time  represents 
more  than  that  period  of  time  in  the  system  being  modeled;  for  example,  in  a  simulation  of 
plant  growth,  running  the  simulation  for  one  second  may  result  in  the  model  advancing  time 
by  one  full  day;  that  is,  simulated  time  advances  faster  than  actual  time.  (2)  The  duration  of 
activities  within  a  simulation  in  which  simulated  time  advances  faster  than  actual  time. 
Contrast  with:  real  time;  slow  time. 

Federation.  A  system  of  interacting  models  and/or  simulations,  with  supporting 
infrastructure,  based  on  a  common  understanding  of  the  objects  portrayed  in  the  system. 

Fidelity.  (1)  The  similarity,  both  physical  and  functional,  between  the  simulation  and  that 
which  it  simulates.  (2)  A  measure  of  the  realism  of  a  simulation.  (3)  The  degree  to  which 
the  representation  within  a  simulation  is  similar  to  a  real-world  object,  feature,  or  condition 
in  a  measurable  or  perceivable  manner. 

Granularity.  Fidelity  and  level  of  detail  of  objects  and  environment.  See  also:  resolution. 

Ground  Truth.  The  actual  facts  of  a  situation,  without  errors  introduced  by  sensors  or  human 
perception  and  judgment. 

High  Level  Architecture  (HLA).  Major  functional  elements,  interfaces,  and  design  rules, 
pertaining  as  feasible  to  all  DoD  simulation  applications,  and  providing  a  common 
framework  within  which  specific  system  architectures  can  be  defined. 

Host  or  Host  Computer.  A  computer  that  supports  one  or  more  simulation  applications.  All 
host  computers  participating  in  a  simulation  exercise  are  connected  by  network(s)  including 
wide  area  networks,  local  area  networks,  and  RF  links. 

Human  Factors.  A  body  of  scientific  facts  about  human  characteristics.  The  term  covers  all 
biomedical  and  psychological  considerations;  it  includes,  but  is  not  limited  to,  principles 
and  applications  in  the  areas  of  human  engineering,  personnel  selection,  training,  life 
support,  job  performance  aids,  and  human  performance  evaluation. 

Hybrid  Simulation.  A  simulation  that  combines  constructive,  live,  and/or  virtual 
simulations,  typically  in  a  distributed  environment.  Such  simulations  combine  simulators 
with  actual  operational  equipment,  prototypes  of  future  systems,  and  realistic 
representations  of  operational  environments. 

Interaction.  The  explicit  action  taken  by  one  object  toward  another  object  or  geographical 
area. 

Joint  M&S.  Representations  of  joint  and  Service  forces,  capabilities,  equipnient,  materiel, 
and  services  used  in  the  joint  environment  or  by  two,  or  more.  Military  Services. 

Legacy  Model.  A  model  developed  in  the  past  which  is  still  in  use  that  was  not  implemented 
using  today's  standards  (e.g.,  software,  communication,  DIS,  ALSP,  etc.).  Some  legacy 
models  have  been  modified  with  interfaces  to  some  of  the  current  standards  extending  their 
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usefulness  and  interoperability  with  newer,  standards  based  models.  Mission  Space.  Mission 
space  refers  to  the  entities,  actions,  and  interactions  that  must  be  represented  to  produce 
credible  simulations  of  the  specific  mission  area  being  addressed.  Mission  space  includes  all 
elements  (e.g.,  logistics,  intelligence,  manufacturing)  which  support  the  simulation  and 
which  are  required  to  achieve  the  desired  goals  and  objectives. 

Live,  Virtual,  and  Constructive  Simulation.  The  categorization  of  simulation  into  live, 
virtual,  and  constructive  is  problematic,  because  there  is  no  clear  division  between  these 
categories.  The  degree  of  human  participation  in  the  simulation  is  infinitely  variable,  as  is 
the  degree  of  equipment  realism.  This  categorization  also  suffers  by  excluding  a  category 
for  simulated  people  working  real  equipment  (e.g.,  smart  vehicles). 

Live  Simulation.  A  simulation  involving  real  people  operating  real  systems.E  The 
categorization  of  simulation  into  live,  virtual,  and  constructive  is  problematic,  because  there 
is  no  clear  division  between  these  categories.  The  degree  of  human  participation  in  the 
simulation  is  infinitely  variable,  as  is  the  degree  of  equipment  realism.  This  categorization 
also  suffers  by  excluding  a  category  for  simulated  people  working  real  equipment  (e.g., 
smart  vehicles).  Virtual  Simulation.  A  simulation  involving  real  people  operating  simulated 
systems.  Virtual  simulations  inject  human-in-the-loop  (HITL)  in  a  central  role  by  exercising 
motor  control  skills  (e.g.,  flying  an  airplane),  decision  skills  (e.g.,  committing  fire  control 
resources  to  action),  or  communication  skills  (e.g.,  as  members  of  a  C4I  team). 

Constructive  Model  or  Simulation.  Models  and  simulations  that  involve  simulated  people 
operating  simulated  systems. 

Mission  Space.  Mission  space  refers  to  the  entities,  actions,  and  interactions  that  must  be 
represented  to  produce  credible  simulations  of  the  specific  mission  area  being  addressed. 
Mission  space  includes  all  elements  (e.g.,  logistics,  intelligence,  manufacturing)  which 
support  the  simulation  and  which  are  required  to  achieve  the  desired  goals  and  objectives. 

Model.  A  physical,  mathematical,  or  otherwise  logical  representation  of  a  system,  entity, 
phenomenon,  or  process. 

Modeling  and  Simulation  (M&S).  The  use  of  models,  including  emulators,  prototypes, 
simulators,  and  stimulators,  either  statically  or  over  time,  to  develop  data  as  a  basis  for 
making  managerial  or  technical  decisions.  The  terms  "modeling"  and  "simulation"  are  often 
used  inter-changeably. 

Modeling  and  Simulation  (M&S)  Accreditation.  The  official  certification  that  a  model  or 
simulation  is  acceptable  for  use  for  a  specific  purpose. 

M&S  Infrastructure.  An  underlying  base  or  foundation;  the  basic  facilities,  equipment,  and 
installations  needed  for  the  functioning  of  a  system.  A  M&S  infrastructure  would  consist  of 
M&S  systems  and  applications,  communications,  networks,  architectures,  standards  and 
protocols,  information  resource  repositories,  etc. 

M&S  Interoperability.  The  ability  of  a  model  or  simulation  to  provide  services  to  and  accept 
services  from  other  models  and  simulations,  and  to  use  the  services  so  exchanged  to  enable 
them  to  operate  effectively  together. 

ModSAF.  Modular  Semi- Automated  Forces  are  a  class  of  CGF  utilizing  a  modular  software 
structure  in  which  model  components  have  well-defined  and  documented  interfaces 
allowing  run-time  reconfiguration  of  model  behavior  to  develop  generalized,  and  more 
sophisticated,  representations  of  reactive  behaviors  and  missions.  ModSAF  provides  an 
open  architecture  that  is  expected  to  be  the  starting  point  for  future  extensions  of  SAFOR 
capabilities. 
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Object.  A  fundamental  element  of  a  conceptual  representation  that  reflects  the  real-world  at 
levels  of  abstraction  and  resolution  appropriate  for  a  simulation,  for  any  given  value  of  time, 
the  state  of  an  object  is  defined  as  the  enumeration  of  all  its  attribute  values. 

Object-Based.  A  software  design  methodology  adhering  to  only  some  of  the  properties  of 
object  oriented  software;  for  example,  Ada  does  not  support  inheritance,  a  key  property  of 
object  oriented  systems,  therefore  Ada  is  often  referred  to  as  an  object  based  language.  See: 
object  oriented.  Object-Oriented.  A  software  design  methodology  that  when  applied  to  DIS 
results  in  the  battlefield  being  represented  by  objects,  where  objects  encapsulate  the 
methods  or  procedures  associated  with  the  object  and  where  objects  communicate  with 
other  objects  by  message  passing.  Examples  of  battlefield  objects  are  platoons  (unit  level), 
tanks  (platform  level),  main  guns  (component  or  module  level),  and  gim  barrels  (part  level). 
One  of  the  main  benefits  of  an  object  oriented  approach  is  the  inherent  modularity;  e.g.,  to 
change  a  tank  model  only  the  tank  object  must  be  changed.  See  also:  object  based. 

Object-Oriented  Language.  A  language  which  best  suits  an  object-oriented  decomposition 
of  software  and  which  provides  the  capability  to  implement  classes  and  objects.  Directly 
supports  data  abstraction  and  classes,  and  provides  additional  support  for  inheritance  as  a 
means  of  expressing  hierarchies  of  classes. 

Object-Oriented  Programming.  Use  of  a  programming  system  that  results  in  programs 
organized  as  cooperative  collections  of  objects,  each  of  which  represents  an  instance  of 
some  class,  and  whose  classes  are  members  of  class  hierarchies  as  defined  by  the 
inheritance  mechanism. 

Open  System.  A  system  in  which  the  components  and  their  composition  are  specified  in  a 
non-proprietary  environment,  enabling  competing  organizations  to  use  these  standard 
components  to  build  competitive  systems.  There  are  three  perspectives  on  open  systems: 
portability  -  the  degree  to  which  a  system  component  can  be  used  in  various  environments, 
interoperability  -  the  ability  of  individual  components  to  exchange  information,  and 
integration  -  the  consistency  of  the  various  human-machine  interfaces  between  an  individual 
and  all  hardware  and  software  in  the  system. 

Protocol.  A  set  of  rules  and  formats  (semantic  and  syntactic)  that  determine  the 
communication  behavior  of  simulation  applications. 

Prototype.  A  preliminary  type,  form,  or  instance  of  a  system  that  serves  as  a  model  for  later 
stages  or  for  the  final,  complete  version  of  the  system. 

Real-Time.  In  modeling  and  simulation,  simulated  time  advances  at  the  same  rate  as  actual 
time;  for  example,  running  the  simulation  for  one  second  results  in  the  model  advancing 
time  by  one  second.  Contrast  with:  fast  time;  slow  time. 

Real-Time  System.  A  system  that  computes  its  results  as  quickly  as  they  are  needed  by  a 
real-world  system.  Such  a  system  responds  quickly  enough  that  there  is  no  perceptible  delay 
to  the  human  observer.  In  general  use,  the  term  is  often  perverted  to  mean  within  the 
patience  and  tolerance  of  a  human  user. 

Real-World.  The  set  of  real  or  hypothetical  causes  and  effects  that  simulation  technology 
attempts  to  replicate.  When  used  in  a  military  context,  the  term  is  synonymous  with  real 
battlefield  to  include  air,  land,  and  sea  combat.  Syn:  real  battlefield. 

Resolution.  The  degree  of  detail  and  precision  used  in  the  representation  of  real-world 
aspects  in  a  model  or  simulation.  See  also:  granularity. 

Scalability.  The  ability  of  a  distributed  simulation  to  maintain  time  and  spatial  consistency 
as  the  number  of  entities  and  accompanying  interactions  increase. 
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Scenario.  (1)  Description  of  an  exercise  ("initial  conditions"  in  military  terms).  It  is  part  of 
the  session  database  which  configures  the  units  and  platforms  and  places  them  in  specific 
locations  with  specific  missions.  (2)  An  initial  set  of  conditions  and  time  line  of  significant 
events  imposed  on  trainees  or  systems  to  achieve  exercise  objectives.  See:  field  exercise. 

Semi-automated  Forces  (SAFOR).  See  Computer  Generated  Forces 

Simulation.  A  method  for  implementing  a  model  over  time. 

Simulation  Environment.  (1)  Consists  of  the  operational  environment  surrounding  the 
simulation  entities  including  terrain,  atmospheric,  bathospheric  and  cultural  i^ormation.  (2) 
All  the  conditions,  circumstances,  and  influences  surrounding  and  affecting  simulation 
entities  including  those  stated  in  (1). 

Simulation  Fidelity.  Refers  to  the  degree  of  similarity  between  the  training  situation  and  the 
operational  situation  that  is  being  simulated. 

Simulation  Time.  (1)  a  simulation's  internal  representation  of  time.  Simulation  tinie  may 
accumulate  faster,  slower,  or  at  the  same  pace  as  sidereal  time.  (2)  The  reference  time  (e.g., 
Universal  Coordinated  Time)  within  a  simulation  exercise,  this  time  is  established  ahead  of 
time  by  the  simulation  management  function  and  is  common  to  all  participants  in  a 
particular  exercise. 

Slow  Time.  The  duration  of  activities  within  a  simulation  in  which  simulated  time  advances 
slower  than  actual  time. 

Standard.  A  rule,  principle,  or  measurement  established  by  authority,  custom,  or  general 
consent  as  a  representation  or  example. 

Stimulate.  To  provide  input  to  a  system  in  order  to  observe  or  evaluate  the  system's 
response. 

Synthetic  Battlefield.  One  type  of  synthetic  environment. 

Synthetic  Environments  (SE).  Intemetted  simulations  that  represent  activities  at  a  high  level 
of  realism  from  simulations  of  theaters  of  war  to  factories  and  manufacturing  processes. 
These  environments  may  be  created  within  a  single  computer  or  a  vast  distributed  network 
connected  by  local  and  wide  area  networks  and  augmented  by  super-realistic  special  effects 
and  accurate  behavioral  models.  They  allow  complete  visualization  of  and  total  immersion 
into  the  environment  being  simulated. 

System.  A  collection  of  components  organized  to  accomplish  a  specific  function  or  set  of 
functions. 

Technical  Infrastructure.  The  internal  framework  that  must  be  built  to  implement  an 
operational  service. 

Time  Step  Models.  Dynamic  models  in  which  time  is  advanced  by  a  fixed  or 
independently-determined  amount  to  a  new  point  in  time,  and  the  states  or  status  of  some  or 
all  resources  are  updated  as  of  that  new  point  in  time.  Typically  these  time  steps  are  of 
constant  size,  but  they  need  not  be. 

Unified  Combatant  Command  (UCC).  One  of  the  unified  combatant  commands  established 
by  the  President  of  the  United  States  according  to  Title  10,  United  States  Code.  Also 
referred  to  as  Combatant  Commands.  (UCCs  include:  US  Atlantic  Command  (abbreviated 
as  USACOM);  US  Central  Command  (abbreviated  as  USCENTCOM);  US  European 


21  of22 


Operational  Requirements  Document 


Command  (abbreviated  as  USEUCOM);  US  Pacific  Command  (abbreviated  as 
USPACOM);  US  Southern  Command  (abbreviated  as  USSOUTHCOM);  US  Space 
Command  (abbreviated  as  USSPACOM);  US  Special  Operations  Command  (abbreviated  as 
USSOCOM);  US  Strategic  Command  (abbreviated  as  USSTRATCOM);  and,  US 
Transportation  Command  (abbreviated  as  USTRANSCOM)). 

Validation.  The  process  of  determining  the  extent  to  which  a  model  or  simulation  is  an 
accurate  representation  of  the  real-world  from  the  perspective  of  the  intended  use(s)  of  the 
model  or  simulation. 

Verification.  The  process  of  determining  that  model  or  simulation  implementation 
accurately  represents  the  developer's  conceptual  description  and  specification.  Verification 
also  evaluates  the  extent  to  which  the  model  or  simulation  has  been  developed  using  sound 
and  established  software  engineering  techniques. 

Virtual  Modeling  and  Simulation.  A  synthetic  representation  of  warfighting  environments 
patterned  after  the  simulated  organization  and  operations  of  actual  military  units. 
Differences  in  the  representation  of  the  simulated  battlefield  (i.e.,  whether  real-world, 
computer  generated,  or  interactive  players  in  simulators)  are  transparent  to  the  participants 
who  interact  with  their  particular  representation  of  the  warfighting  environment. 

Warfare  Simulation.  A  model  of  warfare  or  any  part  of  warfare  for  any  purpose  (such  as 
analysis  or  training). 


ANNEXE 

Coordination 

HQDA,  Deputy  Chief  of  Staff  for  Operations  and  Plans,  DAMO-TR 

Chief  of  Naval  Operations,  Director  of  Naval  Training,  N7,  DONMSMO 

Chief  of  Staff,  US  Air  Force,  AF/XOM 

Commandant  of  the  Marine  Corps,  MCCDC 

Commander  in  Chief,  US  Atlantic  Command,  Code  J3,  J5,  J73 

Commander  in  Chief,  US  Central  Command,  Code  J3,  J5 

US  Commander  in  Chief,  Europe,  Code  J3,  J5 

Commander  in  Chief,  US  Pacific  Command,  Code  J35,  J55 

Commander  in  Chief,  US  Southern  Command,  Code  J3,  J5 

Commander  in  Chief,  US  Space  Command,  Code  J3,  J5 

Commander  in  Chief,  US  Special  Operations  Command,  Code  J3,  J5,  J5-C 

Commander  in  Chief,  US  Strategic  Command,  Code  J3,  J5 

Commander  in  Chief,  US  Transportation  Command,  Code  J3,  J5 

Commander  in  Chief,  US  Army,  Europe,  Code  J3,  J5 

Commander  in  Chief,  Combined  Forces  Command,  Korea,  Code  J35,  J5 

Operational  Plans  and  Interoperability  Directorate,  Joint  Staff,  J-7 

Force  Structure,  Resources  and  Assessments  Directorate,  Joint  Staff,  J-8 

Chairman,  GOSG  Working  Group,  Joint  Staff 

Defense  Modeling  and  Simulation  Office 

Deputy  for  C4I  Modeling,  Simulation  and  Assessment,  Defense 

Information  Systems  Agency 

JSIMS  Joint  Program  Office,  Orlando,  FL 
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